Frontier-generated HTML
Let's examine the HTML that was actually generated in order to give the results we just viewed in the browser (we'll see how to do this later on, but for now, just take my word for it). It looks something like this:
<html> <head> <title>Welcome!</title> <meta name="generator" content="Frontier 5.0 WinNT"> </head> <body alink="#008000" bgcolor="#FFFFFF"
link="#0000FF" vlink="#800080"><p>
<b> Welcome!</b><p>
This is my Web site. I hope you like it here.<p>
<b> Notice.</b><p>
This Web site is under construction.
But, thanks to Frontier,
constructing it will be very easy!<p>
</body> </html>
(Depending on your version of Frontier, and various settings squirreled away in the database, you might see considerably more introductory HTML inside the <head> area or after the </body>. Ignore this for now; I'll explain later how to control whether it gets generated.)
Frontier has generated structural tags, including a <body> tag with our designated color parameters. That's fine because those are things every Web page in the known universe has to have.
But Frontier has also supplied <p> tags before each of our double-returns, and has introduced <b> and </b> tags based on our use of triple-asterisks; this allows you to get up and running very quickly, but on the whole it is not typical of what Frontier does.
Generally speaking, Frontier is very sparing about the way it interferes with your HTML. Frontier does not usually try to generate formatting HTML for you (such as <p> and <b>) except in fairly specialized situations. The first two lines of the original text, the ones about #autoParagraphs and #clayCompatibility, were responsible for Frontier's making this kind of HTML here; whether you use these features is going to be a matter of personal preference.
Directives
Let me explain about those two lines. First of all, notice that they begin with #. This should remind you of the entries in the myFirstSite table that begin with #. In fact, they have the same status. Such lines are called "directives."
For the most part, directives work the same way whether they are table entries or lines in a Web page, except that in a Web page the argument (the value for the directive, which follows it on the same line), if it is to be understood as a string, must be in quotes, whereas in a table it must not, because in a table the fact that it is a string comes from the Kind column for that entry.
There is a simple and powerful hierarchy of directives. The top level is actually in a table we haven't looked at yet, user.html.prefs -- open and examine it now. Here, none of the directives have "#" at their start; nevertheless, these are directives. The hierarchy works as follows:
- A directive in user.html.prefs is applied to every Web page you ever render.
- A directive in a table is applied to every Web page you render from an entry in that table or in a subtable of that table.
- A directive in a Web page is applied to that page only.
- If the same directive appears in more than one of these locations, the one "closest" to the Web page is the one that is applied. In other words, a directive in a Web page overrides the same directive in a table; a directive in a table overrides the same directive in a table that contains it; a directive in a table overrides the same directive in user.html.prefs.
- For certain directives, if no directive appears anywhere, Frontier will supply a value (the default value). For example, it is the case with several directives that if you don't set it to "false," it is as if you had an entry in user.html.prefs setting it to "true."
We have already taken advantage of the directive hierarchy, without even noticing it, in rendering our default page.
You may recall that, back when we rendered websites.samples.randomStuff (the example page), the #template inserted all sorts of information, with your name and email address and the date at the bottom.
At that time, I said that any page living inside websites would have this #template; yet websites.myFirstSite.default evidently lives inside websites, but did not use this #template when it was rendered -- why not?
Because inside websites.myFirstSite, along with default, was a different #template, and this is the template that was actually used, in accordance with the fourth rule above.
Thinking about this, we start to realize how powerful and flexible Frontier is. You can organize your site according to the common aspects of pages.
Suppose you want all pages in your Web site to have a white background color, except for one which is to have a green background color: then you put a #bgcolor directive in your site table that sets a white value, but in the text of that one page you put a #bgcolor directive which has a green value.
Suppose you want all pages in your Web site to have a white background color, except for three special ones which are to have a green background color: then you put a #bgcolor directive in your site table that sets a white value, but put those three pages together in a subtable of your site table, with a #bgcolor directive in that subtable which has a green value.
To see this in action, go into websites.myFirstSite and select the whole "default" line (in selection mode, not content mode), Copy it, and Paste it. This creates a new wp text called "default #1." Rename this to "default copy," to make it a little easier. Open "default copy" for editing, and at the start add a line:
#bgcolor "EEEEEE"
Or if you want to try it with a color name, say (without quotes!):
#bgcolor lightgrey
(That's not quite the same color as "EEEEEE," but "EEEEEE" hasn't a name in system.verbs.colors.)
Now choose Preview Page. The browser shows the page as having a light gray background. "Default copy" is getting its background color from the directive inside itself, overriding the setting in the "myFirstSite" table; whereas, "default" is getting its background color from the directive in the "myFirstSite" table -- since it has no overriding directive inside itself.
You should delete "default copy" now: just select the "default copy" entry in the "myFirstSite" table (in selection mode) and hit the Delete key.
Minding your <p>s and <b>s
Now, to return to the #autoParagraphs and #clayCompatibility directives.
The #autoParagraphs directive governs whether Frontier should insert <p> wherever it sees two returns in a row (before the two returns).
The #clayCompatibility directive (the odd name comes from an earlier Frontier-related project, ClayBasket) governs whether Frontier should surround with <b> and </b> tags every line that begins with "***" (removing the "***").
On the whole I don't use these features of Frontier all that much, so I have gone into user.html.prefs and set my values of autoParagraphs and clayCompatibility to false. But every once in a while they do come in handy, and so I can turn them on for any one page or group of pages with a more localized directive, such as we used in "default" where the directives appear in the page itself.
Try this. In your user.html.prefs table, set autoParagraphs and clayCompatibility to false. Now go into myFirstSite.default and remove the #autoParagraphs and #clayCompatibility lines.
View the page in the browser. The text is interpreted literally, as a single paragraph. Now let's put in our own HTML instead; change myFirstSite.default so that it says:
#title "Welcome!"
<h2>Welcome!</h2> <p>This is my Web site. I hope you like it here.</p> <h2>Notice.</h2> <p>This Web site is under construction.
But, thanks to Frontier,
constructing it will be very easy!</p>
View this in the browser.
Our HTML is untouched, and is interpreted directly by the browser to give the formatting. So you can either put in your own <p> and </p> tags or you can have Frontier put in <p> tags for you. You should not combine the two methods! If you do, you could end up with some fairly skanky HTML.
The title directive
The other directive we just saw operate is the #title directive.
Frontier uses the value of this to create a <title> tag for you, and this shows up in the titlebar of your browser's window when you view the page. The #title directive works hierarchically too, although you can't have a "title" entry in your user.html.prefs table (you can but it does nothing).
Still, it would be unlikely that you would want the same title for multiple Web pages, so the usual use of #title is inside each individual Web page. In fact, here's a little trick I like to use, taking advantage of the hierarchical nature of directives; in my websites table I put a #title directive that says, "Hey, NO TITLE!!!!"
That way, if I forget to add a #title directive in a Web page, I see "Hey, NO TITLE!!!!" in my browser's titlebar when I render the page, and am reminded.
All in your <head>
There are some directives governing whether Frontier puts certain extra material into the <head> region of the HTML.
One is #includeMetaCharset, which determines whether a <meta> tag should be included saying what character set we are using.
I don't particularly want either kind of material added to my HTML, so in user.html.prefs I have set includeMetaCharset to "false"; your tastes may vary, of course.
There is also a #meta directive (for putting in your own <meta> tags) and a #javascript directive, but I'm not going to tell you more about them here. You'll figure them out soon enough if you need them.
Directives come first
Just a couple more things about directives. In a page, to be seen as a directive by Frontier, the text that begins with "#" must come absolutely first in its paragraph. Each directive must be a paragraph of its own.
And, you can save Frontier a lot of work (and yourself a lot of time) if all your directives come first, at the beginning of each page. To let Frontier know you've done this, set the #directivesOnlyAtBeginning directive to "true"; when it renders the page, Frontier will then stop looking for directives in a wp text as soon as it hits a paragraph that doesn't begin with #.
|